Configuring Call Preemption for SBC Emergency Calls
The device supports emergency call preemption for SBC calls by prioritizing emergency calls over regular calls. If the device receives an incoming emergency call when there are unavailable resources to process the call, the device preempts one of the regular calls to free up resources for sending the emergency call to its' destination (i.e., emergency service provider), instead of rejecting it. The device may preempt more than one active call in order to provide sufficient resources for processing the emergency call. Available resources depends on the number of INVITE messages currently processed by the device.
If the device preempts a call, it disconnects the call as follows:
■ | If the call is being setup (not yet established), it sends a SIP 488 response to the incoming leg and a SIP CANCEL message to the outgoing leg. |
■ | If the call is already established, it sends a SIP BYE message to each leg. The device includes in the SIP BYE message, the Reason header describing the cause as "preemption". |
Once the device terminates the regular call, it immediately sends the INVITE message of the emergency call to its' destination without waiting for any response from the remote sides (e.g., 200 OK after BYE). If the device is unable to preempt a call for the emergency call, it rejects the emergency call with a SIP 503 "Emergency Call Failed" (instead of "Service Unavailable") response.
For the device to identify incoming calls as emergency calls, you need to configure a Message Condition rule in the Message Conditions table. Below are examples of Message Condition rules for identifying emergency calls:
Examples of Message Condition Rules for Emergency Calls
Index |
Name |
Condition |
---|---|---|
0 |
Emergency1 - RP header |
header.resource-priority contains 'emergency' |
1 |
Emergency2 - RP header |
header.resource-priority contains 'esnet' |
2 |
Emergency1 - user with providers address |
header.to.url.user=='911' |
3 |
Emergency2 - user with providers address |
header.to.url.user=='100' ||header.to.url.user=='101'||header.to.url.user=='102' |
4 |
Emergency3 - user with providers address |
header.request.uri contains 'urn:service:sos' |
■ | Indices 0 and 1: SIP Resource-Priority header contains a string indicating an emergency call. |
■ | Indices 2 to 4: Destination user-part contains the emergency provider's address. |
The device applies the Message Condition rule only after call classification (but, before inbound manipulation).
The device doesn't preempt established emergency calls.
➢ | To configure SBC emergency call preemption: |
1. | In the Message Conditions table (see Configuring Message Condition Rules), configure a Message Condition rule to identify incoming emergency calls. See above for examples. |
2. | Open the SBC General Settings page (Setup menu > Signaling & Media tab > SIP Definitions folder > Priority and Emergency), and then scroll down to the Call Priority and Preemption group: |
3. | From the 'Preemption Mode' drop-down list (SBCPreemptionMode), select Enable to enable call preemption. |
4. | In the 'Emergency Message Condition' field, enter the row index of the Message Condition rule that you configured in Step 1. |
5. | (Optional) Assign DiffServ levels (markings) to packets belonging to emergency calls: |
● | In the 'Emergency RTP DiffServ' field (SBCEmergencyRTPDiffServ), enter the QoS level for RTP packets. |
● | In the 'Emergency Signaling DiffServ' field (SBCEmergencySignalingDiffServ), enter the QoS level for SIP signaling packets. |
6. | Click Apply. |
The call preemption feature uses only total licensed SBC signaling (SIP) resources and/or the Call Admission Control feature (see Configuring Call Admission Control), and not the number of configured available media (RTP) ports for determining an out-of-resources scenario. Therefore, it's highly recommended that you configure the number of media session legs in the Media Realm table with at least twice the number of SBC signaling resources.